perm filename LETTER.ALL[P,JRA] blob sn#134868 filedate 1974-12-05 generic text, type C, neo UTF8
COMMENT āŠ—   VALID 00002 PAGES
C REC  PAGE   DESCRIPTION
C00001 00001
C00002 00002	\\M1BASL30\M2BASB30\M3NGR25\M4NGR20\M5BASI30\M6BUCK75\F1
C00015 ENDMK
CāŠ—;
\\M1BASL30;\M2BASB30;\M3NGR25;\M4NGR20;\M5BASI30;\M6BUCK75;\F1


\F6\CCIS 280

\F1
\Cas envisioned by
\CJohn Allen, Research Associate
\CStanford University Artificial Intelligence Labs.

\J
I will be teaching the CIS280 (data structures) course in the spring
semester. It will be a non-standard approach to the subject, but one
which has proven to be quite successful and exciting.

Let me give you an introduction to  the course. It grew out
of  a similar course on data  structures I developed at  UCLA  
while teaching as an Assistant Professor in 1970-1972.
Many universities, UCLA included, present data-structure courses in their 
program
at a point when the typical student has no background for assessing
the importance of the techniques. Typically a book like Knuth's is
used. The difficulty is that a background in simple PL/1 or Fortran programming
offers no motivation for studying trees, hashing, garbage collection,
stacks, threading, or any of the other esoteric tricks. My contention is that
the ideas which motivate the techniques, present themselves very naturally in the
context of LISP and its implementation.
My second objection is the use of machine language for discussion
data-structure algorithms. We don't require machine language for numerical
analysis, so why not treat  non-numerical algorithms with the same respect?
LISP is a natural language for such discussions; it not a toy language, but
has a rich history of interesting programming examples.

Once motivation for the study and understanding of data structures is
established, then the techniques can be introduced easily in the
context of implementation of LISP.  Indeed, many of the current tricks
of software implementation originated in LISP's implementation.
But even at this point the appropriate level of abstractness
should be used. All of the data-structure techniques are best understood
at a level higher than machine language. When you want to implement a 
specific technique on a specific machine, then talk about efficiency
and bit-pushing. 
Thus I believe that such a course should make clear the distinction
between ideas, and techniques or tricks. 

I taught five variants of this course at UCLA, each becoming more LISP
and less Knuth. The material has been revised and embellished
during the last two years,
and has been taught  both years at the UC Santa Cruz graduate  workshop. 

The course will attempt to be self-contained because I think LISP
is the best way  to introduce prospective students to  the field and
fewer preconceptions about  programming languages,  the better.  
LISP is an excellent way to take intelligent, but technically naive,
students rapidly to advanced topics in such a way that intuition and the 
continuity of Computer Science is maintained.
Thus
the course  goes  from very  basic  undergraduate material  to  current
research in semantics.

Basically the material falls into  6 areas: 

	\F21.\F1 The mechanics  of the
language;  recursion,    functional  arguments.    Representation  of
algorithms in a  programming language, representation  of domains  as
data structures. 

	\F22.\F1 Evaluation; the importance  of interpretation and
its  relation  to  denotational models.    

	\F23.\F1 Implementation of the static structure of LISP and the
problems of machine orgainzation. Symbol tables, hashing, 
linked allocation, garbage collection, and storage management.

	\F24.\F1 The dynamic structure of LISP and compilers for LISP;  LISP, being
a  very clean  way  to introduce  compilation.   One-pass assemblers, fix-ups,
debugging and programming environments.

	\F25.\F1 Storage and efficiency; more detailed discussion of storage
management; arrays, strings, stacks. Tricks of LISP programming.
Efficiency: double linking, threading, fancy garbage collection....

	\F26.\F1 Implications  for
language  design; given a clear  understanding of LISP,   what can be
done better? Most of this  comes from  my own ideas  on a LISP-like  language
with  user-defined data  structures  and a  semantics  which is  more
amenable to proofs and verifications.
Besides my own ideas, this section will incorporate other more well-known
"extensions" of LISP ideas. Namely the two innovations deriving from PLANNER:
pattern directed invocation, and structured data bases. 

 LISP  is the  most  most  poorly
understood programming language around, and it gets a little tiresome
to see people re-inventing McCarthy's ideas simply because there's no
decent documentation.  

There's a succinct statement by Strachey which
reflects my attitude  about programming languages and the approach
advocated in the course:
\F5"I
always worked on programming  languages because it seems to  me until
you  could  understand those,    you  couldn't understand  computers.
Understanding them doesn't really mean only being able to use them. A
lot of people  can use them  without understanding them."\F1. This quote
appears at the beginning of the chapter on evaluation!

Prequisites? That's hard to say. Interest and an ability to work very
hard are the main requirements. 

Now to more mundane details: the Bookstore will be printing copies of the
current manuscript very shortly. There are currently 26 students enrolled.
(After reading this there may be a sudden decrease, but ...).
If the interest exceeds the supply, then people are bound to get
upset. Also the cost per unit is dependent on the total number of copies
printed.
So if you know of people who might be interested in attending this class and/or 
purchasing the
notes, they  should register your intention immediately.
\.



					John  Allen